## IX. Desechabilidad
### Hacer el sistema más robusto intentando conseguir inicios rápidos y finalizaciones seguras

**Los [procesos](./processes) de las aplicaciones "twelve-factor" son *desechables*, lo que significa que pueden iniciarse o finalizarse en el momento que sea necesario.** Esto permite un escalado rápido y flexible, un despliegue rápido del [código](./codebase) y de los cambios de las [configuraciones](./config), y despliegues más robustos en producción.

Los procesos deberían intentar conseguir **minimizar el tiempo de arranque**. En el mejor de los casos, un proceso necesita unos pocos segundos desde que se ejecuta el mandato hasta que arranca y está preparado para recibir peticiones o trabajos. Mejorar el tiempo de arranque proporciona mayor agilidad en el proceso de [distribución](./build-release-run) y escalado; y lo hace más robusto, porque el gestor de procesos puede mover procesos de forma segura entre máquinas físicas más fácilmente.

Los procesos **se paran de manera segura cuando reciben una señal [SIGTERM](http://en.wikipedia.org/wiki/SIGTERM)** desde el gestor de procesos. Un proceso web para de manera segura cuando deja de escuchar el puerto asociado al servicio (así rechaza cualquier nueva petición), permitiendo que cualquier petición termine de procesarse y pueda finalizar sin problemas. Implícitamente, según este modelo, las peticiones HTTP son breves (no duran más de unos pocos segundos) y, en el caso de un sondeo largo, el cliente debería intentar reconectar una y otra vez cuando se pierda la conexión.

Para finalizar de manera segura, un trabajador (o "worker") debe devolver el trabajo actual a una cola de trabajos. Por ejemplo, en [RabbitMQ](http://www.rabbitmq.com/) un trabajador puede mandar un [`NACK`](http://www.rabbitmq.com/amqp-0-9-1-quickref.html#basic.nack); en [Beanstalkd](https://beanstalkd.github.io), el trabajo se devuelve a una cola automáticamente en el momento en el que el trabajador finaliza. Los sistemas de exclusión mutua como [Delayed Job](https://github.com/collectiveidea/delayed_job#readme) necesitan estar seguros para liberar su candado en el registro de trabajos. Implícitamente, según este modelo, todos los trabajos son [reentrantes](https://es.wikipedia.org/wiki/Reentrancia_%28inform%C3%A1tica%29), lo que se consigue normalmente generando los resultados de manera transaccional, o convirtiendo la operación en [idempotente](http://es.wikipedia.org/wiki/Idempotencia).

Los procesos deberían estar **preparados contra finalizaciones inesperadas**, como en el caso de un fallo a nivel hardware. Aunque es un caso más raro que una finalización mediante la señal `SIGTERM`, se puede dar el caso. Lo recomendable es usar un sistema de colas robusto, como Beanstalkd, que devuelve los trabajos a su cola cuando los clientes se desconectan o expira su tiempo de espera ("timeout"). En cualquier caso, una aplicación "twelve-factor" es una arquitectura que trata finalizaciones inesperadas y peligrosas. El [diseño Crash-only](http://lwn.net/Articles/191059/) lleva este concepto a su [conclusión lógica](http://docs.couchdb.org/en/latest/intro/overview.html).
